Claude Code 攻略 2.3 - Subagent 架构：专业化协作的设计与实践

在学习 Plan Mode 时，你应该注意到 Claude Code 会启动 Explore Agent 和 Plan Agent 来完成探索和规划任务。这两个 Agent 是如何工作的？它们和你正在对话的主 Agent 是什么关系？

当主 Agent 说"我要启动 Explore Agent 去探索代码库"时，背后发生了什么？

如果你把 Agent 类比成函数：

• 主 Agent 就像 main 函数，作为整个程序的主进程
• Explore Agent 和 Plan Agent 就像被调用的子函数
• 通过参数传递信息，完成后返回结果

这就是 Subagent 的核心本质。但在深入技术细节之前，我们需要先理解一个更重要的问题：Subagent 在 Claude Code 架构中的定位是什么？

Subagent 的本质：执行机制而非扩展机制#

很多人第一次接触 Claude Code 时，会把 Subagent、MCP、Skills、Hooks 理解为同一层级的"扩展机制"。这是一个常见的误解。

关键理解：Subagent 不是扩展机制，而是执行机制

让我们回顾一下 Claude Code 的三层架构（详见攻略 2.1）：

┌─────────────────────────────────────────┐
│         执行层 (How to Execute)          │
├─────────────────────────────────────────┤
│  主 Agent                               │
│    ↓ 启动                               │
│  Subagent (独立上下文，并发执行)         │
└─────────────────────────────────────────┘
              ↓ 继承/访问
┌─────────────────────────────────────────┐
│         能力层 (What Can Do)             │
├─────────────────────────────────────────┤
│  系统工具 (内置)                         │
│  MCP Servers (扩展工具)                  │
│  Skills (扩展知识)                       │
│  Hooks (事件监听，自动触发)               │
└─────────────────────────────────────────┘
              ↓ 基于能力构建
┌─────────────────────────────────────────┐
│         应用层 (How to Organize)         │
├─────────────────────────────────────────┤
│  Plan Mode (先规划后执行)                │
│  Subagent 架构 (专业化协作)              │
└─────────────────────────────────────────┘

三层的关系:

• 执行层: Subagent 是执行容器,在独立上下文中运行任务
• 能力层: 提供 Agent 可以使用的工具、知识和机制(包括 Hooks)
• 应用层: 基于能力层构建的高级工作模式(Plan Mode 和 Subagent 架构)

准确的理解：

当主 Agent 启动 Subagent 时，Subagent 会在独立的上下文中执行任务，同时自动继承全局配置的能力（系统工具 + MCP 工具 + Skills 知识 + CLAUDE.md）。Hooks 作为独立的事件监听系统，会在 Subagent 执行过程中的特定时机自动触发，而不是被 Subagent 主动调用。

为什么需要 Subagent#

从上下文工程的角度看，Subagent 解决了三个核心问题：

1. 解决单一上下文的信息过载#

假设你要为一个大型项目添加支付功能，需要探索前端、后端、数据库、配置等多个部分。

如果所有任务都在主 Agent 的上下文中完成：

主 Agent 的上下文（200K tokens）：
├─ 你的历史对话（10K）
├─ 前端代码探索结果（50K）
├─ 后端代码探索结果（50K）
├─ 数据库 schema（20K）
├─ 配置文件（10K）
└─ 当前任务的思考（10K）

问题：
- 上下文爆炸，关键信息被淹没
- Token 成本高
- AI 注意力分散

Subagent 的解决方案：

主 Agent 的上下文（轻量）：
├─ 你的历史对话
├─ 当前任务的核心信息
└─ 各 Subagent 返回的精炼摘要

Explore Agent 1（独立 200K）：
└─ 专注探索前端代码，返回摘要

Explore Agent 2（独立 200K）：
└─ 专注探索后端代码，返回摘要

好处：
- 每个 Agent 专注单一任务
- 主 Agent 只收到精炼信息
- 总体 Token 使用更高效

2. 提供专业化能力#

场景：代码审查

当主 Agent 写完代码后，如果自己审查：

主 Agent 的思维惯性：
- "这里我是故意这么写的"
- "这个边界情况我考虑过了"
- "这个变量名虽然不完美，但能理解"

上下文包含：
- 需求理解
- 设计思路
- 实现过程
- 遇到的问题和解决方案

启动 Code-reviewer Agent（独立上下文）：

Code-reviewer Agent：
上下文只包含：
- 代码本身
- 项目规范
- 最佳实践

没有"写代码时的思维惯性"：
- "这个函数太长了，应该拆分"
- "这个边界情况没有测试覆盖"
- "这个变量名不符合项目命名规范"

这就是 Subagent 的核心价值：专业化分工 + 避免认知盲区

3. 支持并发执行#

场景：为大型项目添加新功能

串行探索（传统方式）：

1. 探索 auth 模块代码     [5 分钟]
2. 探索 database 模块代码  [5 分钟]
3. 探索 API 模块代码      [5 分钟]
总耗时：15 分钟

并发执行（Subagent）：

同时启动 3 个 Explore Agent：
  Agent-1: 探索 auth 模块    [5 分钟]
  Agent-2: 探索 database 模块 [5 分钟]
  Agent-3: 探索 API 模块     [5 分钟]
总耗时：5 分钟（并发执行）

时间效率提升 3 倍。

Task Tool：启动 Subagent 的方式#

在 Claude Code 中，主 Agent 使用 Task tool 来启动 Subagent。

基本语法#

// 伪代码展示 Task tool 的调用
Task({
  description: "探索支付功能实现", // 任务的简短描述（3-5词）
  prompt: `
    探索项目中的支付功能实现：
    1. 找到支付相关的文件
    2. 理解当前的支付流程
    3. 找出可以集成新支付方式的切入点

    项目是一个 Next.js 应用。
  `,
  subagent_type: "Explore", // 选择专业化的 Agent 类型
});

三个参数的作用#

关键理解：

• subagent_type 决定调用哪个专业 Agent
• description 用于用户界面展示和日志记录
• prompt 传递给 Subagent 的详细指令

执行流程#

// 伪代码展示执行流程
async function Task(params) {
  const { subagent_type, description, prompt } = params;

  // 1. 根据 subagent_type 找到对应的 Agent 配置
  const AgentConfig = getAgentConfig(subagent_type); // "Explore"

  // 2. description 用于日志
  console.log(`[Task Started] ${description}`); // 显示给用户

  // 3. 创建新的隔离上下文
  const isolatedContext = createNewContext({
    systemPrompt: AgentConfig.systemPrompt, // Explore Agent 的专业提示词
    tools: AgentConfig.tools, // Explore Agent 可用的工具
    userPrompt: prompt, // 你传入的具体任务
  });

  // 4. 执行并返回结果
  const result = await runAgent(isolatedContext);

  return result;
}

Claude Code 内置的 Subagent 类型#

Claude Code 提供了 50+ 种专业化 Agent，每个 Agent 都有特定的职责和优化的提示词。

通用型 Agent#

Explore Agent（代码探索专家）#

职责：
  - 快速探索代码库
  - 查找文件和代码模式
  - 回答关于代码库的问题

工具集：所有工具

thoroughness 参数：
  - "quick": 基础搜索
  - "medium": 中等深度探索
  - "very thorough": 全面分析

使用场景：
  - "找到所有处理用户认证的代码"
  - "这个项目使用什么数据库？"
  - "支付功能是如何实现的？"

推荐 model：Haiku（探索任务成本更低）

Plan Agent（任务规划专家）#

职责：
- 设计实现计划
- 识别关键文件
- 考虑架构权衡

使用场景：
- Plan Mode 的 Phase 2 自动使用
- 需要设计复杂功能的实现路径

推荐 model：Sonnet（规划需要更强的推理能力）

质量保障型 Agent#

code-reviewer Agent（代码审查专家）#

职责：
- 审查代码质量、安全性、可维护性
- SOLID 原则检查
- 性能和安全漏洞识别

审查维度：
- 架构一致性
- 命名规范
- 错误处理
- 测试覆盖
- 安全漏洞

触发方式：
- 自动：写完代码后主动审查
- 手动：明确请求代码审查

debugger Agent（调试专家）#

职责：
- 诊断错误和异常行为
- 分析测试失败
- 定位 bug 根因

何时自动使用：
- 工具执行返回错误
- 测试运行失败

test-automator Agent（测试自动化专家）#

职责：
- 创建单元、集成、E2E 测试
- 设置 CI pipeline
- 配置 mocking 策略

领域专家型 Agent#

完整列表有 50+ 个专业 Agent，涵盖几乎所有常见的开发场景。

Model 选择策略#

不同 Agent 使用不同的 model，这是成本与质量的平衡：

总结：用低的成本获得较好的结果

并发执行机制#

Subagent 的强大能力之一是支持并发执行。

语法规则#

关键点：所有要并发执行的 Task 必须在同一个响应消息中调用

并发调用示例（伪代码）：

// 单次响应中启动多个 Agent
const [frontend, backend, config] = await Promise.all([
  Task({
    description: "探索前端代码",
    prompt: "找到前端支付相关代码：组件、状态管理",
    subagent_type: "Explore",
  }),
  Task({
    description: "探索后端代码",
    prompt: "找到后端支付 API：路由、Stripe 集成",
    subagent_type: "Explore",
  }),
  Task({
    description: "探索配置文件",
    prompt: "找到所有配置：环境变量、Stripe 配置、依赖",
    subagent_type: "Explore",
  }),
]);

// 三个 Agent 同时执行
// 总耗时：max(Agent1, Agent2, Agent3)

并发数量建议#

并发的代价#

虽然并发可以提升时间效率，但也有成本：

重复探索问题：

场景：添加支付功能到 Next.js 项目

Agent 1 (前端探索):
- 探索 components/ → 找到 Layout.js
- 探索 pages/ → 找到 _app.js
- 读取 lib/stripe.js ← 核心配置

Agent 2 (后端探索):
- 探索 pages/api/ → 找到 API 路由
- 读取 lib/stripe.js ← 核心配置（重复！）
- 读取 package.json

Agent 3 (配置探索):
- 读取 package.json（重复！）
- 读取 .env.example
- 读取 next.config.js

Token 浪费统计：
lib/stripe.js: 500 tokens × 2 次 = 1000 tokens
package.json: 200 tokens × 2 次 = 400 tokens
总浪费: 1400 tokens

为什么还要并发？

这是经典的空间换时间权衡：

总成本 = 时间成本 × 你的时薪 + Token 成本

实际计算（假设时薪 $60/小时）：

串行：90秒 × $1/分钟 + 10K tokens × $0.003 = $1.5 + $0.03 = $1.53
并发：30秒 × $1/分钟 + 12K tokens × $0.003 = $0.5 + $0.036 = $0.536

节省：$1.53 - $0.536 = $0.994 (65% 降低)

最小化重复的策略#

策略 1：精确划分任务边界#

糟糕的划分（大量重复）：

Agent 1: "探索整个项目，关注前端"
Agent 2: "探索整个项目，关注后端"
Agent 3: "探索整个项目，关注配置"

结果：所有人都会读取核心文件

优秀的划分（最小重复）：

Agent 1: "只探索 components/ 和 pages/ 下的 .js/.tsx 文件"
Agent 2: "只探索 pages/api/ 和 lib/ 下的后端逻辑"
Agent 3: "只读取根目录的配置文件（package.json, .env.*, *.config.js）"

结果：边界清晰，几乎无重复

策略 2：使用文件路径过滤#

在 prompt 中明确指定探索范围：

Agent 1 的 prompt:
"探索前端支付组件，范围限定：
- components/**/*.{js,jsx,tsx}
- pages/**/[!api]*.{js,jsx,tsx}  # 排除 pages/api/

不要探索：
- lib/ 目录（由 Agent 2 负责）
- 配置文件（由 Agent 3 负责）"

Agent 2 的 prompt:
"探索后端支付逻辑，范围限定：
- pages/api/**/*.js
- lib/**/*.js

不要探索：
- components/ 目录"

策略 3：分层探索#

第一轮（并发，粗粒度）：
├─ Agent 1: 列出前端目录结构（只用 Glob）
├─ Agent 2: 列出后端目录结构（只用 Glob）
└─ Agent 3: 列出配置文件（只用 Glob）

主 Agent 整合结果，识别关键文件

第二轮（串行，细粒度）：
└─ 主 Agent 精确读取关键文件（避免重复）

上下文管理机制#

Subagent 的上下文管理是其核心特性。

上下文隔离#

主 Agent 的上下文（200K tokens）
├─ 你的历史对话
├─ 已读取的文件
└─ 项目背景

Explore Agent 1 的上下文（独立 200K）
├─ 只有 prompt 传入的信息
├─ 探索前端时读取的文件
└─ 无法看到主 Agent 的历史

Explore Agent 2 的上下文（独立 200K）
├─ 只有 prompt 传入的信息
└─ 与 Agent 1 完全隔离

设计目的：

• 保持 Agent 专注于任务
• 避免被无关信息干扰
• 节省 Token 成本

信息传递机制#

由于 Agent 之间无法直接通信，必须通过显式传递信息。

问题：如何让 3 个并发的 Explore Agent 都知道"这是一个使用 Stripe 的项目"？

方案 A：在每个 prompt 中重复#

Agent 1 的 prompt:
"项目背景：Next.js 应用，使用 Stripe 作为支付方案

任务：探索前端支付组件
1. 找到 Stripe Elements 相关代码
2. 找到支付表单组件"

Agent 2 的 prompt:
"项目背景：Next.js 应用，使用 Stripe 作为支付方案

任务：探索后端支付 API
1. 找到 Stripe SDK 初始化代码
2. 找到创建 Payment Intent 的 API"

优点：明确，每个 Agent 都有完整信息 缺点：重复，公共信息要写多次

方案 B：使用 CLAUDE.md（推荐）#

CLAUDE.md 是"伪全局配置"：

# CLAUDE.md

## 项目技术栈

- 框架：Next.js 12 (Pages Router)
- 支付方案：Stripe Checkout
- 样式：Tailwind CSS

## 支付集成规范

- Stripe 公钥：存储在 NEXT_PUBLIC_STRIPE_KEY
- API 路由：统一放在 pages/api/payment/
- 前端组件：统一放在 components/Payment/

CLAUDE.md 的特殊性：

访问机制：
  主 Agent: 自动读取
  Subagent: 自动读取

生效时机：
  - SessionStart 时加载
  - 每个 Agent 启动时都会读取

作用范围：
  - 整个项目的所有 Agent
  - 跨会话持久化

有了 CLAUDE.md 后，Agent 的 prompt 可以简化：

Agent 1 的 prompt:
"任务：探索前端支付组件
（项目背景已在 CLAUDE.md 中定义）"

Agent 2 的 prompt:
"任务：探索后端支付 API
（项目背景已在 CLAUDE.md 中定义）"

能力继承机制#

关键理解：Subagent 继承能力，不是"调用"能力

配置加载（启动时）：
  ├─ CLAUDE.md → 所有 Agent 启动时读取
  ├─ Skills → 根据关键词自动加载到上下文
  ├─ MCP → 在配置文件中声明，自动连接
  └─ Hooks → 全局监听，不需要 Agent 感知
          ↓
    主 Agent 启动
          ↓
    启动 Subagent (传递 prompt)
          ↓
    Subagent 自动继承:
      - 已连接的 MCP 工具（可以像系统工具一样使用）
      - 已加载的 Skills 知识（影响推理过程）
      - CLAUDE.md 的项目信息
          ↓
    Subagent 执行任务
      - 使用工具时 → Hooks 自动触发
      - 应用知识时 → Skills 提供框架
      - 调用 MCP 工具 → 就像调用 Read 一样自然

类比：操作系统进程

主 Agent = 主进程
Subagent = 子进程 (fork)

子进程继承:
  环境变量 (CLAUDE.md)
  已打开的文件描述符 (MCP 连接)
  共享库 (Skills 知识)

子进程不继承:
  父进程的内存 (上下文隔离)
  父进程的执行状态

信号处理器 = Hooks
  - 全局注册
  - 主进程和子进程都会收到信号

任务划分策略#

如何合理划分任务给不同的 Subagent 是关键技能。

划分维度#

维度 1：按目录划分（探索式任务）#

场景：分析电商项目健康状况

Agent 1: frontend/ 目录
Agent 2: backend/ 目录
Agent 3: database/ 目录
Agent 4: cache/ 目录
Agent 5: message-queue/ 目录

优点：
- 边界清晰，几乎无重复
- 适合探索式任务

缺点：
- 结果分散，需要主 Agent 整合

维度 2：按功能维度划分（分析式任务）#

场景：分析电商项目健康状况

Agent 1: 安全检查（所有目录）
  - 检查敏感信息泄露
  - 检查依赖漏洞
  - 检查权限配置

Agent 2: 性能检查（所有目录）
  - 检查慢查询
  - 检查内存泄漏
  - 检查缓存命中率

Agent 3: 可用性检查（所有目录）
  - 检查 API 健康
  - 检查服务连接
  - 检查错误率

优点：
- 结果结构化，直接可用
- 适合分析式任务

缺点：
- 会重复读取文件
- Token 成本稍高

混合策略（推荐）#

阶段 1：目录级快速探索（并发 5 个）
├─ Agent 1: 列出 frontend/ 的关键文件
├─ Agent 2: 列出 backend/ 的关键文件
├─ Agent 3: 列出 database/ 的关键文件
├─ Agent 4: 列出 cache/ 的关键文件
└─ Agent 5: 列出 message-queue/ 的关键文件

主 Agent 整合：识别需要深入检查的文件

阶段 2：维度级深入检查（并发 3 个）
├─ Agent A: 安全检查（使用阶段 1 的文件列表）
├─ Agent B: 性能检查（使用阶段 1 的文件列表）
└─ Agent C: 可用性检查（使用阶段 1 的文件列表）

主 Agent 整合：生成综合健康报告

为什么这样更好？

• 阶段 1：目录划分，无重复，快速定位关键文件
• 阶段 2：功能划分，有针对性，产出结构化报告
• 总成本：比单一方案更优

任务性质决定划分策略#

最佳实践#

何时使用 Subagent#

适合的场景：

• 大型项目的多模块探索
• 可独立并行的任务（代码审查、测试、文档生成）
• Plan Mode 的探索和规划阶段
• 需要不同专业能力的复杂任务

不适合的场景：

• 单文件或小范围修改
• 任务间有强依赖关系
• 需要频繁交互的任务
• 简单直接的问答

完整实战案例#

场景：为 Next.js 项目实现暗黑模式

阶段 1：并行探索（4 个 Explore Agent）#

// Agent 1: 样式方案探索（使用 Haiku）
Task({
  description: "探索样式方案",
  prompt: `
    探索项目的样式实现方案：
    - 是用 CSS Modules / Tailwind / Styled Components？
    - 主题变量定义在哪里？（:root、theme.js）
    - 颜色变量的命名规范是什么？
    - 是否已有主题切换机制？

    范围：*.module.css, globals.css, tailwind.config.js, theme/ 目录

    输出：
    - 样式方案类型
    - 主题变量位置
    - 现有颜色变量列表
  `,
  subagent_type: "Explore",
});

// Agent 2: 组件使用分析（使用 Haiku）
Task({
  description: "分析组件颜色使用",
  prompt: `
    分析哪些组件需要适配暗黑模式：
    - 列出所有使用硬编码颜色的组件
    - 识别直接引用颜色值的地方（如 #fff, rgb()）
    - 找出使用背景图片的组件（可能需要暗黑版本）

    范围：components/**/*.{tsx,jsx}, pages/**/*.{tsx,jsx}（排除 api）

    输出：
    - 需要修改的组件列表（按优先级）
    - 硬编码颜色的位置（文件:行号）
  `,
  subagent_type: "Explore",
});

// Agent 3: 全局状态探索（使用 Haiku）
Task({
  description: "探索状态管理",
  prompt: `
    探索全局状态管理方案：
    - 使用什么状态管理？（Context / Redux / Zustand）
    - localStorage 如何使用？
    - 是否有全局配置管理？

    范围：context/ 或 store/ 目录, _app.tsx, lib/ 下的工具函数

    输出：
    - 状态管理方案
    - 如何添加全局 theme 状态
    - localStorage 的使用位置
  `,
  subagent_type: "Explore",
});

// Agent 4: 配置和依赖（使用 Haiku）
Task({
  description: "检查配置依赖",
  prompt: `
    检查配置和可用的暗黑模式方案：
    - next.config.js 的相关配置
    - package.json 中是否有主题相关库
    - 是否有 next-themes 或其他主题库

    范围：根目录配置文件, package.json

    输出：
    - 现有主题相关依赖
    - 推荐的暗黑模式实现库
  `,
  subagent_type: "Explore",
});

阶段 2：Plan Mode#

主 Agent 的工作：
1. 接收 4 个 Agent 的结果
2. 分析和整合信息：
   - 项目使用 Tailwind CSS
   - 有 50+ 组件需要适配
   - 使用 React Context 做状态管理
   - 未安装 next-themes 库
3. 识别关键决策点
4. 进入 Plan Mode

Plan Mode 内部：
  Phase 2 会自动启动 Explore 和 Plan Agent
  生成详细的实现计划：
    1. 安装并配置 next-themes
    2. 更新 tailwind.config.js
    3. 修改 _app.tsx 添加 ThemeProvider
    4. 创建主题切换组件
    5. 批量更新组件样式（按模块分批）
    6. 测试和验证

阶段 3：执行实现#

根据 Plan 的任务依赖关系，识别可并发的部分：

串行任务（有依赖）：
Step 1: 安装 next-themes
  └─> 必须完成才能进行后续步骤

Step 2: 配置基础设施（串行）
  ├─ 更新 tailwind.config.js
  └─ 修改 _app.tsx

并发任务（无依赖）：
Step 3: 组件适配（可并发！）
  主 Agent 启动 3 个专业 Agent：
  ├─ Agent A: 修改 Header/Footer 等布局组件
  ├─ Agent B: 修改 Card/Button 等 UI 组件
  └─ Agent C: 修改 Form/Input 等表单组件

Step 4: 创建切换组件（独立任务）
Step 5: 测试验证

关键洞察：

• 先探索后规划：不盲目行动
• 并发探索：利用 Subagent 加速信息收集
• 使用 Plan Mode：复杂任务需要规划
• 执行阶段也可并发：Step 3 的组件适配

局限性与替代方案#

Subagent 的局限#

1. Agent 之间无法直接通信

   • Agent-1 无法告诉 Agent-2："我发现了一个问题"
   • 只能通过主对话协调

2. 每个 Agent 的上下文有限

   • Agent 无法访问主对话的完整历史
   • 只能看到主对话传递的信息

3. Agent 启动有成本

   • Token（上下文初始化）
   • 时间（等待 Agent 完成）
   • API 调用次数

4. 不能自定义 Subagent 类型

   • Subagent 类型是硬编码在 Claude Code 中的
   • 不能添加新的 subagent_type
   • 不能修改现有 Agent 的配置

替代方案：使用 Skills#

场景：你想要一个"电商专家 Agent"

不能这样做：

// 不存在
Task({
  subagent_type: "ecommerce-expert", // 不存在这个类型
  prompt: "分析购物车逻辑",
});

正确做法：创建一个 Skill

# 创建 Skill 目录
mkdir -p .claude/skills/ecommerce-expert/

## <!-- .claude/skills/ecommerce-expert/SKILL.md -->

name: ecommerce-expert
description: 电商业务逻辑分析专家
triggers:

- "电商"
- "购物车"
- "订单"

---

# 电商专家 Skill

你是电商业务逻辑分析专家，专注于：

- 购物车逻辑
- 订单流程
- 库存管理
- 支付集成

## 分析框架

1. 用户流程分析
2. 数据模型分析
3. 业务规则验证

使用方式：

# 手动调用
/ecommerce-expert

# 自动识别
"帮我分析这个项目的购物车实现"
↓
Claude 看到关键词"购物车"
↓
自动加载 ecommerce-expert Skill

Skills vs Subagent#

何时用 Subagent，何时用 Skills#

用 Subagent（内置的专业能力）：

• 需要并发执行
• 需要隔离上下文
• 内置 Agent 已满足需求

用 Skills（自定义领域知识）：

• 需要特定领域的分析框架
• 需要团队共享的最佳实践
• 内置 Agent 不够专业

组合使用（最强大）：

场景：分析一个电商项目的支付功能

Step 1: 加载 Skills
- 加载 ecommerce-expert Skill（电商业务理解）
- 加载 payment-integration Skill（支付最佳实践）

Step 2: 并发启动 Subagents
- 启动 Explore Agent（探索代码结构）
- 启动 security-auditor Agent（安全审查）

Step 3: 主 Agent 整合
- 结合 Skills 的领域知识
- 结合 Subagents 的分析结果
- 产出专业的评估报告

总结#

Subagent 是 Claude Code 架构中的执行机制，不是扩展机制。它通过以下设计实现了强大的能力：

核心特性：

• 独立上下文（200K tokens）：避免信息过载
• 专业化能力：每个 Agent 有特定职责和优化的提示词
• 并发执行：多个 Agent 同时工作，大幅提升效率
• 能力继承：自动继承 MCP、Skills、CLAUDE.md

关键理解：

• Subagent 是执行容器，使用 MCP/Skills，被 Hooks 监听
• 通过 Task tool 启动，三个参数各司其职
• 50+ 内置类型，覆盖常见开发场景
• 不能自定义类型，但可以用 Skills 替代

最佳实践：

• 并发 1-3 个 Agent（推荐）
• 精确划分任务边界（减少重复）
• 使用 CLAUDE.md 共享公共信息
• 混合策略：探索用目录，分析用维度

成本权衡：

• 时间效率 vs Token 成本
• 并发虽有重复，但整体成本更低
• 选择合适的 model（Explore 用 Haiku）

Subagent 是 Claude Code 区别于其他 AI 工具的关键能力之一。理解并善用 Subagent，可以大幅提升开发效率和代码质量。

在下一篇攻略中，我们将深入学习 MCP 生态，了解如何通过 MCP Server 扩展 Claude Code 的工具能力。